In recent history, the World Wide Web (the “Web”) has served two primary roles. First, the Web has provided a mechanism for communication among individuals and businesses, allowing these entities to exchange messages instantaneously. Second, the Web has served as a global library, providing a mechanism for the retrieval and dissemination of information. Today, however, the Web is increasingly used to communicate information from one programming application to another programming application without human intervention, through the use of web services.
A web service is a programming module, located on the Internet that is available for remote invocation. When invoked, the web service implements programming logic and provides functionality for disparate applications across application and organization boundaries. Businesses and other organizations use web services to exchange data with customers over the Internet and between users over an intranet. For example, an e-business wholesaler may use a web service that distributes a list of products to retailers. That e-business wholesaler also would use a web service that receives a purchase order from a retailer and then returns that order with expected shipment dates, the cost of shipping, handling, and the tax on the products. Additionally, a business may use a web service internally over an intranet to exchange data within divisions, such as when a paycheck is calculated using various payroll applications internal to the organization.
A web service client (“client”) is the programming application that invokes the web service. In order for a client to invoke a web service, a message must be sent. Messages are sent based upon protocols developed to promote interoperability among clients and web services. Internet web services are built upon standards and protocols, such as Extensible Mark-up Language (XML), Simple Object Access Protocol (SOAP), and Hypertext Transfer Protocol (HTTP), which have been developed by the World Wide Web Consortium (W3C). XML is a simple, flexible text format for defining data elements in a document. XML has become the dominant message format supporting business-to-business transactions. XML messages often include SOAP elements. When an XML message includes SOAP elements, the XML message is said to be contained within a SOAP “wrapper.” SOAP is a message-based protocol, built around XML, for accessing services on the Internet. SOAP employs XML syntax to send text commands across the Internet using HTTP. HTTP is a standard protocol for communication of messages across the Internet and uses a request/response paradigm. Using HTTP, an XML message sent across the Internet to a web service for processing is a “message request.” After processing the XML message, the web service returns another XML document as a “message response.”
In addition to the protocols discussed above, another element necessary for a client to invoke a web service is access to the appropriate Web Services Description Language (WSDL) document. The WSDL document format is also based on XML. WSDL is required by a web service to describe the capabilities of the web service. Additionally, the WSDL document specifies the web service's location on the Internet and the protocols that clients can use to communicate with the web service. Therefore, in order to invoke a web service, a client needs a proper protocol and the web service location from the appropriate WSDL document.
Each web service has unique requirements that are described in the WSDL document, which are necessary for the client to communicate with the web service. With any web service, the client does not need to know the language in which the web service is implemented. In fact, both the client and the web service are unaware of the other's implementation details. Instead, the client needs only to know the location of the web service, the methods that the client can call on the service, and the message, i.e., data, required to invoke the method. A method is a unique name for a programming task supported by the web service. In the above e-business example, data required to invoke a method to calculate the cost of purchasing and shipping a product may include the type of product and quantity.
Traditionally, a developer programs client code, providing the data required for invoking a method as specified in the WSDL document. In addition to the protocol and the web service location, a proxy is also necessary in order to invoke the method. When a web service is available for use on the Internet, the methods that a client can invoke are said to be “exposed” and available for “consumption” by the web service. A proxy is a programming component that exposes the methods available from the web service to the web service client.
The proxy is included in the client program and is a tool for sending messages from the client to the web service. If the proxy is generated and compiled into the client program at the time of development, the proxy is said to be a static proxy. If the web server provider changes the web service location or otherwise modifies the WSDL document after client code has been developed, the developer must then generate a new static proxy based on the modified WSDL document. Furthermore, the developer must recompile the client code to use the new static proxy and invoke the web service whose location has changed.
To minimize the need to recompile client code, an application may use a dynamic proxy to invoke a web service. A dynamic proxy is a proxy that is created at runtime by passing the Uniform Resource Identifier (URI) of the WSDL document for the web service to an Application Programming Interface (API), such as JAX-RPC, or a Web Services Invocation Framework (WSIF), such as in Apache-Axis WSIF. JAX-RPC is a key JAVA library that enables web services interoperability. Using an API such as JAVA's JAX-RPC, the developer utilizes the WSDL document provided by the web service to generate a web service proxy. Since the actual web service proxy used for invoking the web service is generated dynamically at runtime, instead of during development, the developer does not need to recompile the client code if the WSDL document changes.
WSIF is a JAVA-based framework that also supports communication between a client and web service. WSIF was developed by IBM, Inc. and donated to the Apache Axis foundation as open source code. WSIF is similar to JAX-RPC in that it also supports dynamic invocation of a web service by generating the proxy at runtime so that client code does not need to be recompiled if the web service location changes after development. Although JAX-RPC and WSIF minimize the need to recompile client code by dynamically generating a proxy at runtime to invoke a web service, support is limited to JAVA clients. In contrast to JAVA clients, .Net clients use C#, J#, J script.NET, or VB.Net programming languages. Consequently, the available JAVA API's do not support .Net clients and cannot dynamically invoke a web service for a .Net client at runtime. Moreover, JAX-RPC, WSIF, and other dynamic invocation methods are inherently more difficult to program. For example, the code does the work of a proxy, and therefore, more work must be performed at run time and invocation takes longer. Moreover, clients that rely on them are still susceptible to other maintenance problems, including deprecated APIs and protocols.
U.S. Patent Application 2004/0019696 (the '696 application) discloses a broad method for discovering applications on a network for internal integration of the applications, for associating the applications, and for providing a method of routing information between the applications. The '696 patent application discloses the use of a central repository for application information and web services as a type of application. The '696 application though, does not address applications in an Internet environment and does not address the invocation of web services.
U.S. Patent Application 2004/0111525 (the '525 application) discloses an enhanced service factory as an extension of IBM's Web Service Invocation Framework (WSIF). The enhanced service factory performs dynamic discovery and selection of web service implementations at runtime. The enhanced service factory uses service and port-type information, from a WSDL document, to query the URI and discover candidate web services for that port type. Once a list of the candidate web services is compiled, a particular web service is selected from the list. Selection is based on criteria located in a configuration file. The enhanced service factory generates a proxy for the selected candidate at run time. If the criteria for candidate selection changes, the enhanced service factory generates a new proxy at runtime for that candidate. The '525 application does not disclose calling a web service.
Therefore, a need exists for a middleware application that manages communication between a client and a web service so that changes affecting communication between the client and the web service, including web service relocation, API deprecation, technological changes, or protocol changes, are addressed by the middleware application without a requirement to write new client code.